<html>
<body>
Reports code constructs that always violate nullability contracts, may throw exceptions, or are just redundant, based on data flow analysis.
<p>Examples:</p>
<pre><code>if (array.length &lt; index) {
  System.out.println(array[index]);
} // Array index is always out of bounds

if (str == null) System.out.println("str is null");
System.out.println(str.trim());
// the last statement may throw an NPE

@NotNull
Integer square(@Nullable Integer input) {
    // the method contract is violated
    return input == null ? null : input * input;
}</code></pre>
<p>
  The inspection behavior may be controlled by a number of annotations, such as
  <a href="https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html">nullability</a> annotations,
  <code><a href="https://www.jetbrains.com/help/idea/contract-annotations.html">@Contract</a></code> annotation,
  <code>@Range</code> annotation and so on.
</p>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<ul>
  <li>Use the <b>Suggest @Nullable annotation for methods/fields/parameters where nullable values are used</b> option to warn when a
    nullable value is passed as an argument to a method with a non-annotated parameter,
    stored into non-annotated field, or returned from a non-annotated method. In this case, the inspection will suggest propagating
    the <code>@Nullable</code> annotation. You can also configure nullability annotations using the <b>Configure Annotations</b> button.</li>
  <li>Use the <b>Treat non-annotated members and parameters as @Nullable</b> option to assume that non-annotated members can be null,
    so they must not be used in non-null context.</li>
  <li>Use the <b>Report not-null required parameter with null-literal argument usages</b> option to report method parameters that cannot be
    null (e.g. immediately dereferenced in the method body), but there are call sites where a <code>null</code> literal is passed.</li>
  <li>Use the <b>Report nullable methods that always return a non-null value</b> option to report methods that are annotated as
  <code>@Nullable</code>, but always return non-null value. In this case, it's suggested that you change the annotation to <code>@NotNull</code>.</li>
  <li>Use the <b>Ignore assert statements</b> option to control how the inspection treats <code>assert</code> statements. By default, the option
    is disabled, which means that the assertions are assumed to be executed (-ea mode). If the option is enabled, the assertions will be completely ignored
    (-da mode).</li>
  <li>Use the <b>Report problems that happen only on some code paths</b> option to control whether to report problems that may happen only
    on some code path. If this option is disabled, warnings like <i>exception is possible</i> will not be reported. The inspection will report
    only warnings like <i>exception will definitely occur</i>. This mode may greatly reduce the number of false-positives, especially if the code
    is not consistently annotated with nullability and contract annotations. That is why it can be useful for finding the most
    important problems in legacy code bases.
  </li>
</ul>
<p>
  Before IntelliJ IDEA 2022.3, this inspection was part of the "Constant Conditions & Exceptions" inspection.
  Now, it is split into two inspections:
  "Constant Values" and "Nullability and data flow problems".
</p>
</body>
</html>
